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Summary 

This report documents the results of testing performed using commercial off-the-shelf (COTS) routers 
and Internet protocols (IP’s) t > determine if COTS equipment and IP could be utilized to upgrade 
NASA’s current Space Transportation System (STS), the Shuttle, and the International Space Station 
communication infrastructure. Testing was performed by NASA Glenn Research Center (GRC) personnel 
within the Electronic Systems Test Laboratory (ESTL) with cooperation from the Mission Operations 
Directorate (MOD) Qualification and Utilization of Electronic System Technology (QUEST) personnel. 
The ESTL testing occurred between November 1 and 9, 2000. Additional testing was performed at NASA 
Glenn Research Center in a laboratory environment with equipment configured to emulate the STS. This 
report documents those tests and includes detailed test procedures, equipment interface requirements, test 
configurations, and test results. The tests showed that a COTS router and standard transmission control 
protocols and Internet protocols (TCP/IP) could be used for both the Shuttle and the Space Station if near- 
error-free radio links are pros ided. 


Introduction 

Testing was performed by NASA Glenn Research Center personnel within the Electronic Systems 
Test Laboratory (ESTL) with cooperation from the Mission Operations Directorate (MOD) Qualification 
and Utilization of Electronic System Technology (QUEST) personnel. The ESTL testing occurred 
between November 1 and 9, 2000. Additional testing was performed at NASA Glenn Research Center in 
a laboratory environment witli equipment configured to emulate the Space Transportation System (STS). 
Some of the more significant findings are 

• Tests showed that a COTS router and standard TCP/IP protocols could be used for both the 
Shuttle and the Space Station even with delays of 1200 milliseconds so long as near-error-free radio 
links were provided. However, as the Tracking and Data Relay Satellite System (TDRSS) guaranteed 
channel quality of 1 0“' b t error rate (BER), performance was unacceptable. 
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• High-level data link control (HDLC) framing works well for data links such as those provided by 
the Shuttle and the International Space Station. 

• Nonreturn to zero inverted (NRZI) encoding is mandatory for systems that do not correct for 
phase ambiguity or do not perform scrambling at the data link layer. NRZI will perform the neces- 
sary scrambling and correct for phase ambiguity. 

• The current STS communication system requires all users to fix the radio link. 

Based upon this testing, it is apparent that NASA would be able to deploy COTS networking and 
communication equipment and the TCP/IP protocol suite for both Shuttle and Space Station communica- 
tions if the appropriate resources were brought to fix the data link layer and provide commercial standard 
interfaces to equipment. Deployment of COTS and IP would significantly reduce costs, eliminate many 
interface control documents, and reduce development and testing time. 


Background 

The existing Shuttle and Space Station communications systems utilize nonstandard protocols and 
numerous unidirectional/simplex RF links. The Shuttle's system was designed using the 1960’s and 
1970’s technology. The Space Station system was designed in the 1980's and borrowed heavily from the 
Shuttle design. By doing so, the Space Station remained backward, compatible with the Shuttle. The com- 
munications architectures of both systems are basically a combination of simplex circuits. The systems 
were not designed to incorporate multimedia packetized data on the same communication link. This is 
contrary to commercially based solutions in which various data types and various applications operate, for 
all practical purposes, on individual circuit-switched networks. There are plans to add high-speed applica- 
tions such as high definition television (HDTV), voice over Internet protocol (VoIP), and video over 
Internet protocol (IPTV) to both the Shuttle and Space Station. These new applications are difficult to 
integrate into the legacy system and will certainly stress its capability to meet performance requirements. 
In addition, personnel trained to support these one-of-a-kind systems are nearing retirement or have 
retired. Also, the equipment itself is breaking and the components necessary for repair are no longer 
available. 

By incorporating commercial modems and routers into the communication system, NASA would be 
able to use today’s technology to perform all its communications needs including voice, video, command 
and control, monitoring, security, and transfer of research data between space and the end user. All of 
these functions can be performed better than with the current system at a reduced cost, increased reliabil- 
ity, and increased safety so long as the communication standards — both protocol and interface stan- 
dards — are maintained end-to-end. 

An excellent example of applications of COTS equipment to space-based network has been accom- 
plished by the Russians. The Russian International Space Station (ISS) service module network consists 
of the following COTS products: 

• Ethernet LAN running 100 Base-TX 

• Cabletron SmartSwitch router 

• Shielded cat-5 type cable 

• 3Com 3C589D, or Intel Pro/ 100 PCMCIA Ethernet cards 

The Russians are also using virtual private networks (VPN’s) for security. Finally, all of the module’s 
flight control systems as well as the operational and payload data systems are connected to the same 
LAN. The only change to the COTS products was to change the Cabletron router connectors from a com- 
mercial connector to ruggedized military connectors. One problem the Russian’s are having with this 
system in integration to the NASA one-of-a-kind custom network. 
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Goals 


Three groups participated in the testing: Glenn Research Center/Cisco System, the Mission Control 
Center (MCC), and the ESTL. Each participated with a set of goals. 

The ESTL test team’s goal is to ensure full operation of any communication system over links that 
can degrade to lO -5 BER. ESTL personnel are there to perform pass/fail testing in order to ensure full 
compliance. 

The MCC personnel's go il was to see if a COTS router could replace the current Orbital Communi- 
cation Adapter (OCA) 1 and what modifications, if any, are necessary. 

Glenn Research Center and Cisco Systems personnel had three goals: 

h Determine if COTS equipment could interface to the STS system without expensive 
modifications 

2. Demonstrate use of COTS data networking equipment and protocols with STS and/or ISS with a 
1200 msec delay (600 msec in each link) 

3. Demonstrate applications such as VoIP, IPTV, Telnet, and Wireless LAN's 


RF Link Quality 

All TDRSS links are guaranteed to operate at only 10 -5 . That is the specification that the TDRSS 
contracts to for the Shuttle. Nominal operation however is near-error-free. - 

The signal-to-noise ratio is not guaranteed nor is it provided. Thus, it is very difficult to determine 
what modulation and coding s necessary if one wished to bypass the Shuttle modems. 


Communication Interfaces 

All testing was performed in the STS portions of the ESTL. Thus, the communication links and the 
associated hardware interfaces described are for the STS communications system both onboard (space) 
and at White Sands (ground). 

It has been recognized that the predominant effort during test periods at ESTL is directed to get the 
interfaces working properly. That does not include time spent in preparation for the test. This time is 
almost exclusively due to the use of custom interfaces. Providing standard interface could eliminate better 
than the majority of the test and preparation time. This section provides a good illustration of the added 
work necessary to interface to custom systems. 

Figure 1 shows the STS onboard communications system front end. The most appropriate point to 
incorporate COTS equipmeni would be at the IF interface using a commercial satellite modem. The inter- 
face would be at 647 MHz IF on the forward link and at 1 875 MHz on the return link. This is certainly a 
viable solution technically. Particularly since the Doppler is removed via precompensation and 
postcompensation at White Sands. By using a COTS modem, all interfaces would be commercial stan- 
dards and no special connectors or cabling would have to be developed out of the digital portion of the 
modem. However, this was not considered a viable solution due to the perception of increased risk and 
cost to change existing proven interfaces. In addition, the detailed electronic drawings indicate that por- 
tions of the modulated signal may be used to perform antenna tracking. 


*The OCA is an IBM laptop runnin : Microsoft Remote Access Service (RAS) software and custom interface cards that reside in 
the docking station. One of the functions the custom cards perform on the Shuttle is to bring the radio link quality up from 10~ s to 
near-error-free. 

2 Near -error-free for this system is defined as a link quality of 10 -8 or better. 
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ELECTRONICS ASSEMBLY ONE (EA-1) 


SIGNAL PROCESSOR ASSEMBLY (SPA) 



CH. 3 


Figure 1 . — STS onboard communications system front end. 


The next most appropriate point to incorporate COTS equipment is at the digital interface after the 
modem. Unfortunately there are four different digital interfaces and the electrical and physical character- 
istic vary for each of the four interfaces both on the ground and onboard STS. One interface is associated 
with the 128 kbps forward link. Three interfaces are associated with the return link: the channel 2 FM, 
channel 3 FM and channel 3 PM interfaces. All four links are guaranteed to operate at only 1 0~ 5 (even the 
forward error correction (FEC) encoded link). Channel 2 FM and channel 3 FM are straight binary phase 
shift keying (BPSK), with no coding, no phase ambiguity resolution, and no scrambling. Channel 3 PM is 
implemented as 5 parallel 1 0 Mbps convolutional encoders/decoders with an over guaranteed BER of 
10~ 5 after FEC. 

Figure 2 shows the STS forward link. The space portion would reside onboard the STS. The ground 
portion would reside at White Sands. The numbers on the interfaces corresponds to the ESTL interface 
specification. 

Onboard the Shuttle, the signal processing assembly (SPA) provides a 128 kbps data stream and 
128 kbps clock and interfaces 1 and 2, respectively. Both signals are differential balanced 75 ohm lines 
with the high state at 2.5 V (+1.0 V, -0.5 V) signal line to signal ground and 0.0 V (+0.5 V, -0.0 V) 
signal return line to signal ground. 

On the ground, the data is provided by the router (interface 3), but the clock is provided by the Shuttle 
forward link equipment (interface 4). Thus, the router acts as DTE (data terminal equipment) while the 
Shuttle forward link equipment performs as DCE (data communication equipment). The Shuttle interfaces 
want to see differential balanced lines at 78 ohms with RS422 signal levels. However, the commercial 
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Space 

portion 


Ground 

portion 



Figure 2. — Forward link. 


RS422 specification is for 100 ohms. All connectors are nonstandard connectors and pinouts. Thus, one 
cannot simply connect the RS422, 37-pin connector to the ground or Shuttle interface. Rather, special 
cabling and pinouts are requii ed and have to be generated by each user of the system. 

Figure 3 shows the return link interfaces onboard the Shuttle and on the ground. 

Interfaces 5 and 6 are capable of 8-48 Mbps data and clock, respectively. This is the channel 3 PM 
interface. The signals into the SPA onboard the Shuttle are single ended into 50 ohms. The data signal, 
high signal (logic level 1) is +4.5 to +6.5 V while the low level is -0.5 to +0.5 V. Notice that the clock 
level is different than the data level. The clock level is +3.7 to +6.5 V for logic level 1 and -0.5 to +1.5 V 
for logic level 0. 

Interfaces 7 and 8 are differential balanced lines with logic high at 1.8 to 5.0 V peak-to-peak. Inter- 
face 7 is the channel 2 FM inicrface and is capable of up to 2 Mbps. Interface 8 is the channel 3 FM and is 
capable of up to 4 Mbps. The clocks for channel 2 FM and channel 3 FM are generated from the data and 
take place inside the SPA. 

Interfaces 9 and 10 are the channel 2 FM data and clock, respectively. Signal levels are compatible 
with RS422A. 
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Interfaces 1 1 and 12 are the channel 3 FM data and clock. Signal levels are 50 ohm transistor transis- 
tor logic (TTL) which is quite different than the levels onboard the Shuttle. 

Interface 13 and 14 are the channel 3 PM data and clock. Signal levels are differentially balanced 
emitter coupled logic (ECL). In addition, the balanced signals come from two separate cables that provide 
the plus (+) and minus (-) signals. 

Almost ever} interface signal level is different for different channel modes and between the ground 
and the space interfaces (table I). Because of this, special circuitry and cables must be developed either on 
the ground or in space or both in order to utilize COTS equipment. 



Figure 3. — Return link. 
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TABLE I.— ESTL/QUEST TEST INTERFACE MATRIX 


\— — 

I SOURCE 

| DESTINATION 

Int 

No. 

Signal 

Source 


Signal 

Desc. 

Connector 

■ 

imK 

Dest. 


Signal 

Desc. 

Connector 

Interface 

■ 

1 28 Kbps 
Fwd data 

SPA 

See 

note 1 

75 £2 

Diff. 

Balanced 

Trompeter 
Patch plug 
PL75-9" 

tspc 

75 £2 

(TWC 78- 
2) 

Quest 

Router 

RS422 
78 £2 

Diff. 

Balanced 

Trompeter 

Twinax 

(See 

note 4) 


2 

128 KHz 
clock 

SPA 

See 

note 1/ 

75 a 

Diff. 

Balanced 

Trompeter 
Patch plug 
PL75-9' 

ISP 
75 £2 

(TWC 78- 
2) 

Quest 

Router 

RS422 
78 Q 

Diff. 

Balanced 

Trompeter 

Twinax 

(See 

note 4) 


3 

128 Kbps 
Fw d data 

Quest 

Router 

RS422a 
100 £2 

Diff. 

Balanced 

DB37 P 

Trompeter 

Twinax 

(See 

note 4) 

Shuttle 

Fwd 

Link 

RS422 
78 £2 

Balanced 

Trompeter 
Patch jack 
J152 

Quest 

Supplied 

Adapter 

■ 

128 KHz 
clock 

Shuttle 

Fwd 

Link 

RS422 
78 £2 

Balanced 

Trompeter 
Patch jack 
J72-F 

TSP 
75 £2 

(TWC 78- 
2) 

Quest 

Rouler 

RS422 
78 £2 

Diff. 

Balanced 

Trompeter 

Twinax 

(See 

note 4) 


5 

8-48 
Mbps 
Rtn data 

Quest 

Router 

RS422a 
Or HSSI 
See 

note 5 

Diff. 

Balanced 

DB37 S 

Coax 
50 ft 

SPA 

See 

note 2 

50 £2 

Single- 

ended 

BNC 

PL20-3 

Quest 

Supplied 

Adapter 

6 

8-48 

MHz 

clock 

Quest 

Router 

RS422a 
Or HSSI 
See 

note 5 

Diff. 

Balanced 

HD5U S 

Coax 
50 ft 

SPA 

See 

note 2 ' 

so a 

Single- 

ended 

BNC 

PL20-3 

Quest 

Supplied 

Adapter 

7 

2 Mbps 
Rtn data 

Quest 

Router 

RS422a 
100 £2 

Diff. 

Balanced 

DB37S 

Trompeter 

Twinax 

(See 

note 4) 

SPA 

1.8- 

5.0V/ 

75 a 

Diff. 

Balanced 

Trompeter 
Palch plug 
PL75-9 

Quest 

Supplied 

Adapter 

8 

4 Mbps 
Rtn data 

Quest 

Router 

RS422a 

ioo n 

Diff. 

Balanced 

DB37S 

Trompeter 

Twinax 

(See 

note 4) 

SPA 

1.8- 
5.0 V/ 
75 £2 

Diff. 

Balanced 

Trompeter 
Patch plug 
PL75-9 

Quest 

Supplied 

Adapter 

9 

2 Mbps 
Rtn data 

ESTGT 

1R 

RS422a 
100 £2 

Diff. 

Balanced 

Trompeter 
Patch jack 
J72-F 

Twinax 
100 £2 

Quest 

Router 

RS422 
78 £2 

Diff. 

Balanced 

Trompeter 

Twinax 

(See 

note 4) 

Bal/S.E. 

buffer 

10 

2 MHz 
clock 

ESTGT 

1R 

RS422a 

100 a 

Diff. 

Balanced 

Trompeter 
Patch jack 
J72-F 

Twinax/ 
100 £2 

Quest 

Router 

RS422 
78 £2 

Diff, 

Balanced 

Trompeter 

Twinax 

(See 

note 4) 

BaLS.E. 

buffer 

11 

4 Mbps 
Rtn data 

ESTL 

Bit 

sync 

TTL/ 
50 £2 

Single- 

Ended 

Trompeter 
Ptitch jack 
J3-F 

Coax 
50 £2 

Quest 

Router 

RS422 
78 £2 

Diff. 

Balanced 

Trompeter 

Twinax 

(See 

note 6) 


12 

4 MHz 
clock 

ESTL 
bit sync 

TTL/ 
50 £2 


Trompeter 
Patch jack 
J3-F 

Coax/ 
50 £2 

Quest 

Router 

RS422 
78 £2 

Diff. 

Balanced 

Trompeter 

Twinax 

(See 

note 6) 


1 

8-48 

MHz 

clock 

FEC 

ECL, 1 Diff. 

50 £2 : Balanced 

(-2V) (See 

note 3) 

Trompeter 
Patch jack 
J72-F 

Coax/ 
50 ft 

Quest 

Router 

HSSI 
(See 
note 5) 

Diff. 

Balanced 

Coax/ 
50 ft 


14 

8-48 
Mbps 
Rtn data 

FEC 

ECL/ 1 Diff 
50 £2 Balanced 

(-2V) (See 

note 3) 

Trompeter 
Patch jack 
J72-F 

Coax 
50 ft 

Quest 

Router 

■ 

Diff. 

Balanced 

Coax 
50 ft 



Note 1: O.Ov (+0.5v, -O.Ov) signal rtn line to ■ ignal gnd. Low State: O.Ov (+0.5v. -O.Ov) signal line to signal ground. High State: 2.5v (+1.0v, -0.5v) 
signal rtn line to signal gnd 

Note2i Data Logic 1: +4.5v to +6.5v Data L igic 0: -0.5v to +0.5v, Clock Logic 1: +3.7v to +6.5v Clock Logic 0: -0.5v to +1.5v 

Note 3: Balanced signal comes from two sepi late cables that provide the (+) and (-) signals 

Note 4: Trompeter twinax cable PCB0W30PC B-120. Quest w ill provide AD78 barrel adapter, if needed. 

Note 5: For rates greater than 8 Mbps, HSSI h ill be used. HSSI cable cut and diffline brought out to BNC pin connectors. BNC shield to signal ground. 
Requires translator circuit. TTL 50 £2 lo difFECL. For rates less than 8 Mbps, the RS422 serial interface can be used. Trompeter tw inax cable 
PCB0W30PCB-120. Quest will supp y the AD78 barrel adapter, if needed. Requires translator circuit. TTL 50 £2 to diff TTL RS422 standard. 
Note 6: Trompeter twinax cable PCBOW30P< B-120. Quest w ill provide AD78 barrel adapter, if needed. Requires translator circuit, TTL 50 £2 to 


diff TTL RS422 standard. 
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Network Configurations 


This section documents the test configurations and connectors for a system with and without the satel- 
lite channel emulator hardware used to provide delay. The purpose of this section is to document the con- 
nector and system configurations. The complexity of the various configurations necessary to test custom 
systems due to the nonstandard connectors and clock and data generation are illustrated. 

Figure 4 shows the network layout when no delay units are used. This is the configuration that would 
be used in the actual network. The ground and space networks are mirror images. Each router has four 
serial ports available with two active. Each router had one 100BaseT fast Ethernet network interface card 
(NIC) and a VoIP module. The VoIP modules used could handle two phones. Other VoIP modules could 
actually tie into a private branch exchange (PBX). The fast Ethernet interface is connected to a 24-port 
IP switch, which is used to connect additional hosts as well as a wireless access point to enable wireless 
communications to the local area network (LAN) via the IEEE802.il wireless Ethernet specification. 

It is possible to implement this configuration with only one serial port on the ground router and one 
serial port on the space router when RS422 clock rates and signal levels are used by both forward and 
return links (fig. 16). We utilized two units in order to simplify the clock and connector configurations. 

In addition, by deploying two units, the architecture is pictorially more representative of an actual system. 
Also, for a system using a return link with high-speed serial interface (HSSI) rates (up to 50 Mbps) a sec- 
ond serial interface is required. 

Figure 5 shows the connector layout for the space-to-ground link when no delay units are in the sys- 
tem. The 37 socket-to-twinax connectors are custom made. 

The transmitting serial port on the ground router is setup as a DTE and receives clock from the White 
Sands 3 equipment on the RS422 station-timing lines (connector 4). When at White Sands, only data is 
input into the transmit portion of the ground terminal via the station-timing lines (connector 3). The clock 
is then derived from the data. However, when running back-to-back testing to verify connectors and rout- 
ing, the clock is required by the space router. This clock is provided by the transmit-timing lines of the 
RS422 interface. In addition, when running back-to-back, a clock source is needed into the station-timing 
lines. We provided this by employing an unused serial port on the 4-port NIC to provide just a clock. 

The receiving serial port on the space router is configured as a DTE. Clock and data are provided by 
the STS receiving equipment and are input to connectors 1 and 2 via the receive-data and receive-timing 
on the RS422 serial interface. 

STS 

Connections 

— ► • 

1 28 kbps 


2 

STS 

Connections 
2 Mbps 

Figure 4. — Network topology without delay units. 

Tor this document. White Sands refers to the White Sands ground portion of the ESTL STS test facility and interfaces. The 
interfaces in the ESTL are the same as those at the actual White Sands facility. STS refers to the space portion of the network. 
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Figure 6 shows the connectors for the space-to-ground link when no delay unit is present. The twinax- 
to-37-pin and twinax-to-37-sc cket connectors are custom made. 

The transmitting serial port on the space router is configured as a DCE and provides clock and data. 
The Cisco routers can generate clocks at discrete rates. One of those rates is very close to 1 28 kbps. This 
is the setting used in the tests. The STS space-to-ground generates its own clock from the data provided. 
However, when running back to-back tests with the groundside router, a clock is required. Thus the clock 
out of the STS router can provide a clock via the return-timing lines. 

The receiving serial port on the White Sands router is configured as a DTE. Clock and data are pro- 
vided by the White Sands receiving equipment and are input to connectors 9 and 10 or 1 1 and 12 via the 
receive-data and receive-timing lines on the RS422 serial interface. 


Wh te Sands Space Transportation System (Shuttle) 

Forward Link Forward Link 


sO/Tx 

10.0.4.2 

DTE 



TROMPETERTWINAX CABLE 
PCB0W30PCB-1 20 with 
AD78 BARREL ADAPTERS 

EIA/TIA-449 DTE 


CAB-SS-449MT 

— 


P 

Data r pv 




Clock ' X 




_ 

« Clock P X 


TROMPETERTWINAX CABLE 
PCB0W30PCB-1 20 with 
AD78 BARREL ADAPTERS 


EIA/TIA-449 DTE 


© — w 

— 



1 CAB-SS-449MT 

x clock : 






_ 






sO/Rx 

10.0.4.1 

DTE 



DB-60P 
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Figure 5. — Connectors for ground-to-space with no delay. 
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Figure 6. — Connectors for space-to-ground with no delay. 
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Figure 7 shows the network topology when delay units are inserted into the system. The delay units 
are Adtech SX/14 satellite channel emulators. As in the no-delay topology, it is possible to implement this 
configuration with only one serial port on the ground router and one serial port on the space router and 
one delay unit when RS422 clock rates and signal levels are used by both forward and return links. Again, 
we utilized two units in order to simplify the clock and connector configurations. 

Figure 8 shows the location of the connectors when a delay unit is present and the configuration of the 
serial ports on the routers. The White Sands transmitting and receiving serial ports are configured as 
DTE's. The STS receiving port is configured as a DTE while the transmitting serial port onboard STS is 
configured as a DCE. All DTE ports receive clock whereas the DCE port provides clock. 
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Figure 7. — Network topology with delay units. 
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Figure 8. — Connector location with delay units present. 
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Figure 9 illustrates the configuration of the Adtech SX/14 channel emulators. The ground-to-space 
delay unit is configured as DTE/to DTE. The channel timing is from the internal synthesizer via the termi- 
nal timing input of the “west” connector for back-to-back testing and via the external input when inter- 
faced to the ESTL test facility . The space-to-ground delay unit is configured as DTE/to DCE with channel 
timing from the internal synthesizer referenced to the DCE reeeive-timing clock. 
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Figure 9. — Adtech SX/14 configurations. 
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Figure 10 shows the special connectors required for the forward and return links when the Adtech 
SX/14 channel emulator units are deployed. Note, “S” is socket and “P” is pin. Also note that there is a 
special connector labeled connector 7. This connector goes to one of the spare serial interfaces on the 
ground router. That interface is configured as a DCE and provides clock when running back-to-back 
testing. 

Figure 1 1 illustrates the configuration utilized for back-to-back testing with the delay units present. 
The clock off serial port 3 of the transmitting serial interface is used to provide clock thereby emulating 
the White Sands ground terminal uplink equipment. Note, the delay units could also be used for generat- 
ing errors into either portion of the link. This was the setup used to validate the routing setup within the 
space and ground based router configurations. This was also the configuration used at Glenn Research 
Center to troubleshoot the high packet loss seen for UDP testing at BER's of 10 -6 while at ESTL and to 
complete testing of multicast protocols using IP/TV (see Testing section for details). 
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Figure 10. — Forward and return link connectors with delay unit present. 
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Figure 12 illustrates the configuration utilized for testing within ESLT. The data on the ground trans- 
mit side is slaved to the clock provided by White Sands. Here, that clock is input to the external clock on 
the Adtech. The Adtech provided the delay whereas the ESTL equipment generated errors by injecting 
noise into the RF chain. The A dtechs were also used to generate errors in a more controlled fashion to 
validate some of the results seen under ESTL-generated error conditions. This was done to corroborate 
that the Adtechs could be usee in place of ESTL for protocol and networking-related testing and still pro- 
vide valid results. 
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Figure 1 1 . — Back-to-back testing configuration. 
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Figure 12. — ESTL testing configuration. 
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Test Tools and Configurations 


TCP transfers were run using the TCP extensions for selective acknowledgment (SACK) (ref. 1 ), 
time-stamps, and large windows (ref. 2 ). The linux TCP implementation was used at both the sender and 
receiver. The payload packet size was 1440 bytes as this is typical of Ethernet packets and is small 
enough to ensure no fragmentation when all TCP extensions are utilized. 

We use the network performance application ttcp to perform the majority of our tests. The ttcp appli- 
cation we used was modified to enable setting of the priority bits for quality of service (QoS) testing. 
Some example ttcp commands are shown below. The “-s” transfers a fixed repeated sequence between 
hosts as a memory to memory transfer. The is used for UDP transfer. The sets the buffer size — 
this is useful for TCP testing to set the send and receiver buffers thereby tuning the system. A 300,000- 
byte buffer will result in a 2-Mbps maximum data transfer for a 1 .2-second round-trip time. The sets 
the number of packets sent. The “-p” sets the priority bit. The “ host ” is the receiving hosts IP address. 
Finally, the “ < filename ’ 1 redirects a file to be transferred rather than a memory-to-memory transfer. The 
is meaningless when redirection is used. 

ttcp -s -t -11440 -b300000 -n5000 -p6 host 

ttcp -it -t -11440 -b30000 -n5000 -p6 host < filename 

ttcp -t -11440 -b30000 -n5000 -p6 host < filename 

The majority of the tests were performed using the 2-Mbps space-to-ground link for data transfer and 
the 128-kbps ground-to-space link for acknowledgments. 


Tests 

Four tests were performed that provided measurable engineering data. These are described under this 
test section. These tests include Packet InterNet Gopher (PING ) tests, all O’s/l's, TCP performance test- 
ing, and UDP performance testing. Unless otherwise stated, the testing was performed using the channel 2 
FM, 2-Mbps return-link for file transfer and the 128-kbps forward-link for acknowledgments. Figure 13 
shows the detailed network configuration including the addressing. 
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PING 


Packet InterNet Gopher (PING) is part of the standard TCP/IP suite of protocols. PING is extremely 
useful for debugging network problems. It allows one to check their connectivity with other devices, or to 
check whether your own TCP 'IP stack is working properly. A PING is an echo test that uses the Internet 
control message protocol (ICMP) to determine if a host is active. A message is sent from one host to an- 
other and a reply returned. PING's are used to verify a particular host is up and running as well as to 
verify routes exist between hosts. PING's also provide the round-trip time measurements. 

We used PING's to verify network configurations and setup — particularly to verify correct settings in 
the delay units. PING's were used prior to all TCP and UDP tests as well a prior to all application demon- 
strations to ensure correct network configuration. 


Phase Ambiguity 

Neither channel 2 FM noi channel 3 FM perform phase ambiguity. COTS router interfaces are not 
designed to perform phase ambiguity as this is considered a radio modem function. Thus during our initial 
tests to validate router configuration, the serial interface on the routers were initially configured for 
HDLC framing and the defau t channel encoding, NRZL (nonretum-to-zero level). The polarity of the 
differential data lines had to be manually inverted relative to the clock lines approximately 50 percent of 
the time in order to correct the phase ambiguity. This was later corrected by configuring the serial inter- 
faces for nonretum-to-zero in .erted (NRZI) — see All O's/l's for a detailed explanation. 


All O’s/l's 

Neither the channel 2 FM nor channel 3 FM links perform scrambling. Because of this, the data 
goodput 4 will degrade severely when large strings of l's or 0's are sent over the RF link. 

The serial interfaces on the routers were initially configured for HDLC framing and NRZL encoding. 
The tests were performed on the space-to-ground 2-Mbps link operating at nominal (near-error-free) per- 
formance. File transfers for f les containing all l's or all 0's were run using ttcp. The following com- 
mands were entered from hosts 10.0.3.51 and 10.0.2.54, respectively: 

ttcp -t -11440 -b30000 -n: 000 -p6 10.0.2.54 < allones 

ttcp -r -11440 -b30000 -n5000 -p6 

For the channel 2 FM unscrambles link, the NRZL encoding resulted in an unusable communication 
link with approximately 50 percent errors. 

The serial interfaces on the routers where then configured for HDLC framing and NRZI encoding. 
The result was 0 BER. In addilion, NRZI encoding corrected for phase ambiguity resolution problem. 

NRZI is a differential encoding technique. Differential encoding inherently corrects for phase ambi- 
guity. This comes with some .ost, as single bit errors on the transmission path will result in two succes- 
sive errors in the decoded bit stream. 


4 Goodput refers to the measurement of actual data successfully transmitted from the sender!, s ) to receiver! s). Goodput is the use- 
ful data throughput. It excludes overhead, retransmission, and other unacceptable or redundant data at the receiving host. 
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TCP Performance 


TCP is the underlying reliable transport protocol for the majority of the Internet services. It is used by 
application protocols such as FTP (file transfer protocol) (telnet, secure shell, and Web browsing to name 
a few). TCP was originally designed to be reliable and robust to accommodate military requirements such 
as satellite communications and nuclear war. As the use of TCP grew, improvements were added to the 
protocol. One of the critical improvements was to add congestion control algorithms to TCP so that the 
TCP would perform well on a shared network. Current implementations of TCP assume that a packet loss 
is the result of congestion. TCP initially increases its transmission rate exponentially. This is called slow 
start. Once a packet is perceived to have been lost, TCP halves its transmission rate and then continues to 
grow its transmission rate linearly by approximately one packet every round-trip time. The rate halving 
and linear rate increase is why TCP will perform very poorly for single flows (only one user on the net- 
work) on long-delay, error-prone links. 

TCP performance tests were ran for nominal links and for links with 10 -6 BER. The ttcp application 
was used for these tests for both memory-to-memory transfers and file transfers. The buffer size was set 
to 300,000 bytes at the receiver in order to optimally tune TCP for maximum throughput without going 
into self-congestion. The packet payload length was set to 1 440 bytes to ensure no packet fragmentation 
due to application of TCP extensions. Large windows, selective acknowledgments and time-stamp 
options were enabled. A large file of approximately 12 Mbytes of random data was selected for the final 
tests. The data link used HDLC framing with NRZI encoding. The following commands were entered 
from hosts 10.0.3.51 and 10.0.2.54, respectively: 

ttcp -t -11440 -030000 -n5000 -p6 10.0.2.54 < vel2posd0 

ttcp -r -11440 -b30000 -n5000 -p6 

Figures 14 and 15 show TCP transfers under error- free and lO -6 BER conditions over a 1.2 second 
delay. The maximum throughput for TCP was close to the link speed of 2 Mbps under error-free condi- 
tions. However, once errors were introduced, the performance degraded quickly due to the linear rate 
increase and the long round-trip times. This is evident in figure 15 by the number of retransmissions and 
the inability of TCP to fill the link. Here, average TCP throughput was approximately 70 kbps for BER of 
10 A Packet loss was approximately 2 percent for a BER of 10" 6 as read off the router interface counters. 
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Figure 14. — Tuned TCP/BER = 0. 
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The results show that TCP will guarantee delivery of all data, even over a highly errored link with 
long delays. However, when attempting to transfer large files over error-prone, long-delay links, TCP is 
not recommended. A rate-bas:d user datagram protocol (UDP) file delivery application may be more 
appropriate particularly if the link is not shared. 


UDP Performance 

The UDP tests were performed in order to get packet throughput numbers for the return and forward 
links. These tests became the most difficult to perform and resulted in conflicting and initially unex- 
plained performance numbers while testing in ESTL at Johnson Space Center (JSC). The UDP tests were 
recreated at GRC. The GRC test results should be used for packet throughput. However, the ESTL test 
did reveal some necessary rooter configurations necessary to ensure proper operation. The following sec- 
tion contains the detailed test setup at ESTL and GRC as well as the test results. 

Figure 13 is representative of the test setup. The fast Ethernet ports on the 3640 routers auto-negoti- 
ated with the 2900 Catalyst switches to 100BaseT (100 Mbps). The labtops’ Ethernet NIC's also auto- 
negotiated with the 2900 switches to 100BaseT. The data rate out of the space router’s serial port was set 
to 2,015,232 bps — this was the closest discrete frequency to 2 Mbps that the router could provide. The 
data link layer protocol was HDLC with NRZI encoding. (It is very important to understand HDLC fram- 
ing to understand the test resi Its of this section. An explanation of HDLC operation is provided in the 
appendix.) 

The initial return-link throughput measurements were obtained by clearing the counters and then run- 
ning UPD ttcp tests using the following command on host 10 0.3.51: 

ttcp -u -s -t -11440 -b300(H) -n5000000000 -p6 10.0.2.54 

This test method turned cut to generate misleading results. Since host 10.0.3.51 was operating on a 
100 Mbps link and the serial etum link was set for approximately 2 Mbps, the router had to drop approxi- 
mately 98 percent of the packets at the output buffer of the serial card. We did not consider this to be a 
problem as we were only concerned with counting packets transmitted out of the interface, not dropped 
at the output buffer. We were mistaken however as apparently the interface could not handle the packet 
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dropping, HDLC framing, and NRZI encoding as the test results will indicate. This test configuration 
does not represent real networks as one would never put 100 Mbps of data into a 2-Mbps link. In hind- 
sight, a better test would have been to use a rate-limited transfer application such as DBS (ref. 3) rather 
than ttcp. 

The measurement technique used to determine packet throughput was to read out the number of pack- 
ets transmitted from the space serial port. Once we had sufficient packets transferred, the ttcp application 
was terminated and the packets transited out of the space serial port and the packet received by the ground 
serial port were recorded along with other meaningful information such as Communications Research 
Center (CRC) errors and aborts. Assuming no losses, the packet counts should match to within perhaps 
three or four packets (due to the inability to precisely clear the counters between transmitter and receiver). 
In addition, ttcp was run at the receiving host to get instantaneous throughput measurements and tcpdump 
was run at the receiving host to view any unusual behavior. 

Initial test results indicated no packet loss and 2-Mbps throughput at nominal performance and 
70 percent packet loss at 10 -6 BER with the majority of the packets received being rejected due to CRC 
errors or aborts. This result did not match theory and was most unexpected. In addition, the result did not 
match the packet loss of approximately 2 percent for TCP operation over a 10 -6 BER link. Observations 
of the tcpdump real-time data at the receiving hosts showed a starting and stopping of the data flow. This 
type of bursty behavior is indicative of loss-of-frame synchronization. 

Since option for ttcp results in the same payload pattern being transmitted, the GRC team hypoth- 
esized the payload errors were resulting in false HDLC frame headers, which would then cause the entire 
payload to shift and be out of synchronization. However, this should not happen with HDLC as the pay- 
load bytes should never match the HDLC flag bytes (see HDLC in appendix). 

In order to remove the possibility that the repetitive payload pattern was causing problems, a script 
was written to continuously transmit any specified file using the UDP capabilities of ttcp. 

The ESTL test team provided a small file consisting of eight copies of a 127-bit pseudorandom pat- 
tern. Results using this small file we saw a packet loss of approximately 2 percent at 10 -6 BER, which 
matched our TCP results. However, this packet size was very small and most of the time the link was idle 
waiting for the transmitting system to loop and reload the file. Thus, we did not have any packet drops at 
the output buffer of the return-link serial port. 

The GRC team ran the same tests at ESTL using the 12 Mbyte file. The results were again 70 percent 
packet loss at 10 -6 BER. The GRC team was able to duplicate the 70 percent packet loss with either the 
ESTL equipment degrading the link or by setting the ESTL equipment for nominal operation and having 
the Adtech SX/14 provide l.OxlO -6 BER. 

On December 12, 2000, GRC personnel duplicated the JSC ESTL setup and repeated the UDP 
streaming tests in GRC’s laboratory using the Adtech SX/14 channel emulators to create delay and errors. 
Setup included using a 100-Mbps source into a fast-Ethemet NIC and outputting via a serial NIC 
(serial 0/1 ) at 2 Mbps. GRC personnel noted that if the serial output interface was not overload, a packet 
loss of approximately 1 to 2 percent resulted at 10 -6 BER. GRC personnel tested this using a script that 
basically looped many times through a ttcp call where ttcp sent a small number of packets. The tests indi- 
cate that the Cisco router NT-4 interface cannot perform both the HDLC framing with bit stuffing and 
packet dropping at the output of the output queue when excessive data is being forced through that link. 

By applied committed access rate (CAR) rate-limiting QoS to the input of the output queue, 1 to 
2 percent packet loss for UDP packets at 10 -6 BER was obtained. 
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For QoS techniques and commands see: 

Policing and Shaping Overview 

http://www.cisco.com/univerul/cc/td/doc/product/software/iosl20/12cgcr/qos_c/qcpart4/qcpolts.htm 
Configuring Committed Access Rate 

http://www.cisco.com/univerLd/cc/td/doc/product/software/iosl20/12cgcr/qos_c/qcpartl/qccar.htm 

The results indicated that one can obtain theoretical UDP packet throughput using HDLC framing and 
NRZI encoding. In addition, ( AR rate-limiting should be applied to the input of the output queue on the 
transmit portion of a WAN link (see appendix for UDP streaming test results). 


Demonstrations 

A number of applications were run over the nominal and errored links to demonstrate the ease and 
extent to which Internet protocols and technologies can be utilized by the Shuttle and Space Station. The 
applications included telnet, secure shell (ssh). Web-base control, FTP, and VoIP. QoS techniques were 
also demonstrated. 

Telnet and ssh were utilized routinely over the 1.2-second round-trip delay to setup and monitor 
equipment remotely. The space and ground portions of the ESTL network are located in different rooms. 
Use of telnet or ssh were usee to set up the space side equipment from the ground side and visa versa. 
Telnet and ssh were able to operate even at 10 -5 BER. Because of the small packet sizes and small 
amount of data transfer, link efficiency is not an issue for telnet and ssh. 

The ttep application used for testing TCP performance demonstrated the ability to transfer large files. 
FTP would result in similar performance. Thus, near-error-free links are required for good bandwidth 
efficiency when using FTP. 

VoIP was demonstrated between the space and ground links. The VoIP demonstrated used with 
G729.R8 compression required 8 to 1 1 kbps data throughput in each direction when talking (22-kbps 
duplex). The VoIP also has silence suppression so that no information is transmitted if no one is speaking. 
NIC cards in the space and ground routers w'ere connected to analog wireless phones. Calls could be made 
by simply dialing the assigned phone number. Standard VoIP configurations were used. The VoIP per- 
formed well at nominal settings. During one call, the return link was degraded until the phone line went 
dead. This link was then returned to the nominal state resulting in the still open phone line reestablishing 
connectivity on its own. VoIP also worked at 10 -5 BER including call setup and teardown. Operation 
over such poor links is possible because the packets are relatively small and the decompression technol- 
ogy can compensate for some dropped packets. Note, 10~ 5 packet loss is a normal occurrence on a con- 
gested network. 

Web-based control was demonstrated by remotely configuring the Cisco/Aironet wireless access 
points. The access points can be controlled and monitored using telnet or a standard Web browser. 

A QoS test was done witli VoIP and a file transfer running simultaneously. Two configurations were 
demonstrated. In the first configuration VoIP was given a precedence of 5 while a file transfer was give a 
precedence of 0. With VoIP having the higher priority process, the file transfer took longer than in case 2. 
No degradation in voice quality was apparent. In the second configuration, VoIP was given a precedence 
of 5 while a file transfer was given a precedence of 6. Here, the files transfer occurred more quickly while 
voice quality degraded with t ie sound breaking up periodically. 
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Figure 16. — Network topology supports multicast. 


We attempted to run IPTV using the duplex routing over simplex links, but were unsuccessful to date. 
IPTV uses multicast protocols as the transport delivery protocol. As of May 2001, we have been unable to 
find a way to trick the simplex links to accept multicast protocol. One alternative, available only if the 
channel 2 FM or channel 3 FM circuits are used, is to apply only one serial interface on the WAN connec- 
tion as shown in figure 16. The serial interface cards are capable of handling separate receive and transmit 
clock rates. The problem with this configuration, however, is that video is a high-rate application. Thus, 
one would much prefer to use the channel 3 PM, 48-Mbps link. The 48-Mbps link would require use of a 
high-speed serial interface (HSSI). HSSI interfaces use differential ECL levels. If the topology of figure 
16 is used, proper level translation must be performed between the COTS HSSI interfaces and the NASA 
ground and space equipment. 

Work is currently taking place in the commercial sector to develop routing protocols for networks 
with two separate asymmetric unidirectional links. These technologies directly apply to many NASA 
mission network topologies including the Shuttle and the Space Station. 


Conclusions 

The results of the tests showed that a commercial off-the-shelf (COTS) router and standard TCP/IP 
protocols could be used for both the Shuttle and the Space Station even with delays of 1200 milliseconds 
as long as near-error-free radio links are provided. The results also show that high-level data link control 
(HDLC) framing works well for data links such as those provided by the Shuttle and the International 
Space Station. In addition, for systems that do not correct for phase ambiguity or do not perform scram- 
bling at the data link layer, nonreturn to zero inverted (NRZI) encoding is mandatory. NRZI will perform 
the necessary scrambling and correct for phase ambiguity. 
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Recommendations 


Use of TCP can result in inefficient use of the bandwidth under congested or errored links with long 
bandwidth delay products. If, and only if, large files are being transferred often and if, and only if, you 
own and understand the dynamics and bandwidth allocations of the end-to-end network, a rate-based reli- 
able file delivery protocol may be appropriate to deploy to improve link utilization. 

Based on the results of this testing, it appears that NASA would be able to deploy COTS networking 
and communications equipment provided that resources were brought to bear to improve the current chan- 
nel quality threshold of lO - ' 1 1>ER. The current architecture requires each user to adapt to this channel 
quality, which precludes the use of COTS and standard interfaces. Bringing the resources to bear to im- 
prove the channel quality to a least 10 -8 BER would allow NASA to utilize COTS networking and com- 
munication equipment and the TCP/IP protocol suite for both Shuttle and Space Station communications. 
Deployment of COTS and IP would significantly reduce costs, eliminate many interface control docu- 
ments, and reduce developme it and testing time. 
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APPENDIX 


Test Equipment 


TABLE H.— TEST EQUIPMENT 


QUANTITY 

DESCRIPTION 

2 

Cisco 3C4() router with 4 port serial card. VoIP card, 10000 card 

2 

Cisco 2 ll 00 24-port 10/100 switch 

1 

Cisco IP I V broadcast server 

1 

Cisco IP TV control server 

2 

Adtech NX/14 Data Channel Simulator (to add delay) 

2 

Linux'W indows Laptop PC's with network performance tools 

i 

Laptop PC w ith IPTV client software loaded 

2 

Aironet Access Points (wireless Ethernet) 

i 

Wireless Ethernet PCMCIA cards (for laptops) 

4 

Analog telephones 

1 

VCR (video source) 

1 

PC monitor (for IPTV servers) 

Numerous 

Cables, adapters, and connectors 


Test Documentation 

The test results and documentation are available on the Web at http://ctd.lerc.nasa.gov/5610/ 
relpres.html as a compressed tile. This tarball contains the tests performed at JSC and includes 

• linux_bin: The linux binary files for programs utilized to perform network testing. 

• misc: misc files including Excel spreadsheets, PowerPoint presentations, and MSWord 
Documents 

• nov7: Test data run o i Nov 7 

• nov8: Test data run o 1 Nov 8 

• nov9: Test data run o 1 Nov 9 

• dec 12: Test data run on Dec 12 identifying and correcting 70 percent UPD packet loss at 10 -6 
BER 

• router_configuration;- : router configurations used for the tests 

• scripts: script files used for the tests 

• scr: Source file of the programs utilized to perform network testing 

• test_data_files: test d ita files 


High-Level Data Link Control (HDLC) 

High-level data link control, also known as HDLC (ref. 4 ), is a bit-oriented data link control protocol, 
and falls within layer 2, the dita link layer, of the open systems interface (OSI) model. 

HDLC is a protocol deve oped by the International Organization for Standardization (ISO) under the 
ISO standards ISO 3309 and ISO 4335. It supports both half-duplex and full-duplex communication lines, 
point-to-point (peer-to-peer) and multipoint networks, and switched or non-switched channels. The proce- 
dures outlined in HDLC are designed to permit synchronous, code-transparent data transmission. Other 
benefits of HDLC are that the control information is always in the same position, and specific bit patterns 
used for control differ dramatically from those in representing data, which reduces the chance of errors. 
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HDLC uses the term “frame” to indicate an entity of data (or a protocol data unit) transmitted from 
one station to another (fig. 17). Every' frame on the link must begin and end with a flag sequence field (F). 
The flag sequence is a 01 1 1 1 1 10 octet. Two other bit sequences are used in HDLC as signals for the sta- 
tions on the link. These two bit sequences are 

• Seven 1 ’s but less than 15 signals an abort signal. Then stations on the link know there is a prob- 
lem on the link. 

• Fifteen or more 1 \s indicate that the channel is in an idle state. 

Flags are continuously transmitted on the link between frames to keep the link active. The time be- 
tween the transmission of actual frames is called the interframe time fill. The interframe time fill is ac- 
complished by transmitting continuous flags between frames. The flags may be in 8 bit multiples. 

If an octet has a bit sequence of 01 1 1 1 1 10, but is not a flag field, HLDC uses a technique called bit- 
stuffing to differentiate this bit sequence from a flag field. Once the transmitter detects that it is sending 
five consecutive l’s, inserts a 0 bit to prevent a “phony” flag. 

At the receiving end. the receiving station inspects the incoming frame. If it detects five consecutive 
l’s, it looks at the next bit. If it is a 0, it pulls it out. If it is a 1, it looks at the 8th bit. If the 8th bit is a 0, it 
knows an abort or idle signal has been sent. It then proceeds to inspect the following bits to determine 
appropriate action. This is the manner in which HDLC achieves code-transparency. HDLC is not con- 
cerned with any specific bit code inside the data stream. It is only concerned with keeping flags unique. 

If there is noise on a line, a HDLC flag may get damaged or data between flags may get damaged and 
would then look like the start or end of a packet. These errors will result in two or more packets appearing 
in error and are why we should expect to see approximately 2x1 CT 6 packet loss rather than 1CT 6 packet 
loss for a 10"^ BER link. 

The following example illustrates two good packet flows and the result of a false flag (FFlag): 

Flag-Data-Data-Data-Data-Flag-Flag-Data-Data-Data-Data-Flag-Flag-Data-Data-Data-Data-Flag 

Flag-Data-FFlag-Data-Data-Flag-Flag-Data-Data-Data-Data-XXXX-Flag-Data-Data-Data-Data-Flag 


Lost packet Results in two packets being lost 



Field Name 
Flag Field (F) 

Address Field (A) 

Control Field (C) 

Information Field (I) 

Frame Check Sequence (FCS) 
Closing Flag Field (F) 


Size (in bits) 

8 bits 
8 bits 

8 or 1 6 bits 

Variable; not used in some frames 
1 6 or 32 bits 
8 bits 


Figure 1 7. — HDLC frame. 


NASA/TM- 


2002-211310 


24 




UDP Testing Script 


#!/bin/tcsh 

#This script takes a file port a file into ttcp for UDP transmission 

# command is udp_stream count host file 

# count = the number of time.' the file should be sent 

# host = hostname or IP address of the receiving host 

# file = the file to be redirected into ttcp 

# 

# ttcp -u -1 1440 -b300000 $2 •: $3 

#The tepdump filename is the 1st and only parameter input and is required. 

# 

# 

echo “There will be $1 sets ol ttcp UDP file transfers" 
set ent = $ 1 
while ( $cnt >= 1 ) 

echo “This is a run $cnt couni ing down" 
set ent = 'expr Sent - 1 ‘ 
ttcp -t -u -11440 -b300000 S2 < $3 
while ( “'ps -a I grep ttcp' " != ) 

end 
end 

echo “DONE" 


Router Configurations 

Some subtle key-routing configurations and commands that are required to make simplex routing 
over duplex links work properly include 

• Use “static routes” or simplex links 

• Use “no keep-alive” on simplex links 

• Use “ignore-ded” on DTE interface (be sure cables are connected first!) 

• Set “clock rate" on DUE interfaces 

• Use NRZI encoding. It solves all 0’s, all l’s, and phase ambiguity problems. 

• Use HDLC framing. 

• Use the “transmit” command on the receiving interface to transmit on the sending interface. 

- intSl(Rx) 

- transmit int S0(T k ) 


SHUTTLE ROUTER - named “Columbia” 

Columbia l#sho conf 

Using 1508 out of 129016 bytes 

t 

version 12.0 

service timestamps debug uptime 
service timestamps log uptime 
no service password-encryption 
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hostname Columbia 1 
! 

enable password cisco 

t 

; 

l 

t 

I 

ip subnet-zero 
no ip domain-lookup 
; 

ip multicast-routing 
ip dvmrp route-limit 20000 
ip audit notify log 
ip audit po max-events 100 
cns event-serv ice server 
! 
i 
i 
t 

voice-port 2/0/0 

I 

voice-port 2/0/1 

; 

dial-peer voice 1 pots 
destination-pattern 456 
port 2/0/0 

! 

dial-peer voice 10 voip 
destination-pattern 123 
session target ipv4: 10.0.2.1 

t 

dial-peer voice 2 pots 
destination-pattern 258 
port 2/0/1 

i 

dial- peer voice 20 voip 
destination-pattern 147 
session target ipv4: 10.0.2.1 

i 

process-max-time 200 

t 

interface Serial0/0 

transmit-interface Serial0/1 

ip address 10.0.4.1 255.255.255.0 

nrzi-encoding 

no ip directed-broadcast 

ip pirn dense-mode 

no ip mroute-cache 
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no keepalive 
ignore-dcd 

i 

interface SerialO/1 

ip address 10.0.5.1 255.255.255.0 

nrzi-encoding 

no ip directed-broadcast 

ip pim dense-mode 

no keepalive 

clockrate 2015232 

I 

interface Serial0/2 
no ip address 
no ip directed-broadcast 
shutdown 

i 

interface SerialO/3 
no ip address 
no ip directed-broadcast 
no keepalive 
clockrate 128000 

! 

interface FastEthemetl/0 
ip address 10.0.3.1 255.255.2 55.0 
no ip directed-broadcast 
speed 10 

i 

interface Hssi3/0 

no ip address 

no ip directed-broadcast 

shutdown 

i 

ip classless 

ip route 10.0.0.0 255.0.0.0 Sei ial0/l 
no ip http server 
! 

! 

t 

line con 0 
password cisco 
transport input none 
line aux 0 
line vty 0 4 
password cisco 
login 
i 
! 

end 
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GROUND ROUTER - named “quest” 

quest l#sho conf 

Using 1490 out of 129016 bytes 

t 

version 12.0 

service timestamps debug uptime 
service timestamps log uptime 
no service password-encryption 

I 

hostname quest 1 

t 

enable password cisco 


ip subnet-zero 
no ip domain-lookup 

I 

ip multicast-routing 
ip dvmrp route-limit 20000 
ip audit notify log 
ip audit po max-events 1 00 
cns event-service server 


voice-port 2/0/0 

! 

voice-port 2/0/1 

i 

dial-peer voice 1 pots 
destination-pattern 123 
port 2/0/0 

! 

dial-peer voice 10 voip 
destination-pattern 456 
session target ipv4: 10.0.3.1 

! 

dial-peer voice 2 pots 
destination-pattern 147 
port 2/0/1 

! 

dial-peer voice 20 voip 
destination-pattern 258 
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session target ipv4: 10.0.3. 1 

! 

process-max-time 200 

i 

interface SerialO/O 
ip address 10.0.4.2 255.253.235.0 
nrzi-encoding 
no ip directed-broadcast 
ip pirn dense-mode 
no ip mroute-cache 
no keepalive 
ignore-dcd 

i 

interface Serial0/1 

transmit-interface Serial0/0 

ip address 10.0.5.2 255.255.255.0 

nrzi-encoding 

no ip directed-broadcast 

ip pirn dense-mode 

no keepalive 

ignore-dcd 

i 

interface Serial0/2 
no ip address 
no ip directed-broadcast 
shutdown 

! 

interface Serial0/3 
no ip address 
no ip directed-broadcast 
shutdown 

i 

interface FastEthemet 1 /0 
ip address 10.0.2.1 255.255.255.0 
no ip directed-broadcast 
speed 100 
full-duplex 

! 

interface Hssi3/0 

no ip address 

no ip directed-broadcast 

shutdown 

! 

ip classless 

ip route 10.0.0.0 255.0.0.0 Sei ial0/0 
no ip http server 

t 

i 
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! 

line con 0 
password cisco 
transport input none 
line aux 0 
line vty 0 4 
password cisco 
login 

| 

i 

end 


UDP Streaming Test Results for December 12, 2000 

The following are two test results. Rate limiting was set at 1896000 bps. BER was 10" 6 binominal 
distribution. In trial 1, no rate limiting was performed. For this short test, packet loss was approximately 
78 percent with 17876 packets transmitted and 2367 received. For trial 2, we rate-limited at the input 
queue of the output buffer. Note, there still was 100 Mbps of data coming into the rate-limiting queue. 
The packet loss was approximately 2.4 percent with 7397 packets transmitted and 7213 received. 
Conclusions: 

• HDLC and NRZI perform well even in simplex link. 

• The router can only take so much abuse in one functional location or it is overloaded. Therefore, 
use rate-limiting on the input of the output queues for noncongestion friendly traffic such as UDP. 


Router processor can only do so much. 

We need to rate-limit UDP traffic and everything works! 


Space router confg details 

i 

access-list 101 permit udp any any eq 5001 
ip cef 

interface Serial0/1 
ip address 10.0.5.1 255.255.255.0 
no ip directed-broadcast 
ip accounting access-violations 
ip pirn dense-mode 

rate-limit output access-group 101 1896000 10000 30000 conform-action transmit exceed-action drop 

no keepalive 

nrzi-encoding 

clockrate 2015232 

no cdp enable 
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Trial 1 (no rate limit for port 5432) 


[ivancic@katrinajoy decl2]$ ttcp -u -s -t -11440 -b300000 -n50000000 10.0.2.200 -p5432 


space#sho int sO/1 
Serial0/1 is up, line protocol is u 
Hardware is M4T 
Internet address is 10.0.5.1/24 
MTU 1500 bytes, BW 1544 Kbu, DLY 20000 usee, 
reliability 255/255, txload 128- 255. rxload 1/255 
Encapsulation HDLC, cre 16. loopback not set 
Keepalive not set 

Last input never, output 00:00:08, output hang never 
Last clearing of “show interface" counters 00:02:33 
Input queue: 0/75/0 (size/max/drops); Total output drops: 58921 1 
Queueing strategy: weighted fan 

Output queue: 0/1000/64/58921 1 (size/max total/threshold/drops) 
Conversations 0/2/256 (active/max active/max total) 

Reserved Conversations 0/0 (allocated/max allocated) 

5 minute input rate 0 bits/sec. 0 packets/sec 
5 minute output rate 780000 bit ./sec, 62 packets/sec 
0 packets input, 0 bytes, 0 no buffer 
Received 0 broadcasts, 0 runts 0 giants, 0 throttles 
0 input errors, 0 CRC, 0 frame . 0 overrun, 0 ignored, 0 abort 
17876 packets output, 26300540 bytes, 0 underruns 
0 output errors, 0 collisions, 0 interface resets 
0 output buffer failures, 0 output buffers swapped out 
0 carrier transitions DCD=up DSR=up DTR=up RTS=up CTS=up 
ground#sho int s0/l 
Serial0/1 is up, line protocol is up 
Hardware is M4T 
Internet address is 10.0.5.2/24 
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usee, 
reliability 192/255, txload 1/255, rxload 27/255 
Encapsulation HDLC, crc 16, loopback not set 
Keepalive not set 
Transmit interface is Serial0/0 
Last input 00:00:07, output nev :r, output hang never 
Last clearing of “show interface " counters 00:01 :50 
Input queue: 0/75/0 (size/max/d tops); Total output drops: 0 
Queueing strategy: weighted fair 

Output queue: 0/1000/64/0 (sizc/max total/threshold/drops) 
Conversations 0/0/256 (active- tnax active/max total) 

Reserved Conversations 0/0 (allocated/max allocated) 

5 minute input rate 217000 bits, sec, 7 packets/sec 
5 minute output rate 0 bits/sec, 0 packets/sec 
2367 packets input, 3478486 bytes, 0 no buffer 
Received 0 broadcasts, 0 runts. 0 giants, 0 throttles 
14419 input errors, 14416 CRC, 0 frame, 0 overrun, 0 ignored, 3 a 
bort 

0 packets output, 0 bytes, 0 underruns 
0 output errors, 0 collisions. 0 interface resets 
0 output buffer failures, 0 output buffers sw apped out 
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0 carrier transitions DCD=up DSR=up DTR=up RTS=up CTS=up 
space#sho interfaces rate-limit 
SerialO/1 
Output 

matches: access-group 101 

parants: 1896000 bps, 10000 limit, 30000 extended limit 
conformed 0 packets, 0 bytes; action: transmit 
exceeded 0 packets, 0 bytes; action: drop 
last packet: 714104ms ago, current burst: 28564 bytes 
last cleared 00:00:52 ago, conformed 0 bps, exceeded 0 bps 


Trial 2 (rate limit for port 5001 ) 


[ivancic@katrinajoy dec 12]$ ttcp -u -s -t -11440 -b300000 -n50000000 10.0.2.200 -p5001 

space#sho int s0/l 
Serial0/1 is up, line protocol is up 
Hardware is M4T 
Internet address is 10.0.5. 1/24 
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usee, 
reliability 255/255, txload 81/255, rxload 1/255 
Encapsulation HDLC, crc 16. loopback not set 
Keepalive not set 

Last input never, output 00:00:02, output hang never 
Last clearing of “show interface” counters 00:02: 16 
Input queue: 0/75/0 (size/max/drops); Total output drops: 256470 
Queueing strategy: weighted fair 

Output queue: 0/1000/64/0 (size/max total/threshold/drops) 

Conversations 0/2/256 (active/max active/max total) 

Reserved Conversations 0/0 (allocated/max allocated) 

5 minute input rate 0 bits/sec, 0 packets/sec 
5 minute output rate 491000 bits/sec. 30 packets/sec 
0 packets input, 0 bytes, 0 no buffer 
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
7397 packets output, 10876892 bytes. 0 underruns 
0 output errors, 0 collisions, 0 interface resets 
0 output buffer failures, 0 output buffers swapped out 
0 carrier transitions DCD=up DSR=up DTR=up RTS=up CTS=up 

ground#sho int s0/l 
Serial0/1 is up, line protocol is up 
Hardware is M4T 
Internet address is 10.0.5.2/24 
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usee, 
reliability 191/255, txload 1/255, rxload 44/255 
Encapsulation HDLC, crc 16, loopback not set 
Keepalive not set 
Transmit interface is SerialO/0 
Last input 00:00:20, output never, output hang never 
Last clearing of "show interface” counters 00:04:19 
Input queue: 0/75/0 (size/max/drops); Total output drops: 0 
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Queueing strategy: weighted fail 

Output queue: 0/1000/64/0 (size, max total/threshold/drops) 
Conversations 0/0/256 (active/max active/max total) 

Reserved Conversations 0/0 (allocated/max allocated) 

5 minute input rate 271000 bits/sec, 22 packets/sec 
5 minute output rate 0 bits/sec, (' packets/sec 
7213 packets input, 10598850 bytes, 0 no buffer 
Received 0 broadcasts, 0 runts. 0 giants, 0 throttles 
580 input errors, 578 CRC, 0 ftame, 0 overrun. 0 ignored. 2 abort 
0 packets output. 0 bytes, 0 unt erruns 
0 output errors, 0 collisions. 0 interface resets 
0 output buffer failures, 0 output buffers swapped out 
0 carrier transitions DCD=up I )SR=up DTR=up RTS=up CTS=up 


space#sho int s0/l rate-limit 
Serial0/1 
Output 

matches: access-group 101 

params: 1896000 bps, 10000 li nit, 30000 extended limit 

conformed 7390 packets. 1087o644 bytes; action: transmit 

exceeded 256470 packets, 377523840 bytes; action: drop 

last packet: 77128ms ago, current burst: 29592 bytes 

last cleared 00:03:07 ago, conformed 462000 bps, exceeded 16069000 bps 


Test Personnel 

Researchers: W. Ivancic and T. Bell, NASA Glenn Research Center, and D. Shell, Cisco Systems 

QUEST (ESTL Test Sponsor): P. Carreon, NASA Johnson Space Center Code DV2 

ESTL Test Team Members: 

Test Director 
Test Conductor 
ESTL Senior Test Engineers 
Test Project Engineers (TPE) 

Test Data Coordinator 
Quality Assurance Specialist 

ESTL Area Engineers: 

CT&RA 
ESTGT 
SEN-1 
SITA 
TCC-1 
SLSA 

ESTL Systems Support (as required): 

ESTL Intercom System F.T. Shetz, Jr. 

EMACS/EDS F.R. Sims 

Test Technician/Backup S.L. Connaly/I.A. Vences 


C. A. Lansdowne 
T.B. Jenkins 

P.D. Hangsleben/F.T. Shetz, Jr. 
G.L. McKinney 
K.J. Jolley 

D. P. Bette 


P.R. Flores 
P.I. Yamaguchi 
F.J. Ward 
A.F. Buchanan 
P.D. Hangsleben 
H.M. Ponder, Jr. 
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